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Addendum to The Sniffer 
Operation and Reference Manual 


With the release of Version 1.2 of The Sniffer, Network General Corporation included a number 
of features that were not provided in Version 1.0 and have not yet made it to the Operation 
and Reference Manual. This Addendum describes the new features. It has been trimmed so that 
it will fit inside the back cover of your copy of the Operation and Reference Manual. 


The Addendum you are now reading has three portions: 


Ii A summary list of the principal new features, followed by a more 
detailed description of each. There’s also a list of minor 
improvements or corrections made since the first release. 


2. A new version of Appendix C, on writing and linking your own 
protocol interpreters to work with the Sniffer. 


3. A new combined Index, integrating coverage of the original manual 
and the Addendum. 


The Addendum is intended to follow the Operation and Reference Manual. Its pages are 
numbered starting at 151, so that they do not overlap with those of the original manual. You 
should mark the original Appendix C and the original Index as obsolete. (You might want to 
remove those pages; but that isn’t essential.) 


Here’s a list of the additions. Following the summary list, each is 
N ew F eatures described separately. 


Traffic Generator: Lets the Sniffer generate frames so you 
can load the network to test its response. (See page 153.) 


Playback Mode: Lets you display the data from a saved 
file as if it were being captured live. (See page 156.) 


Partial Frame Capture: Lets you collect only the first so- 
many bytes of each frame, to avoid clogging the buffer with 
long frames. (See page 159.) 


Higher-Level Addresses: In its name tables, the Sniffer 
now includes as part of every station address the protocol 
level at which the address occurs. You’ll see the two together 
(labeled Type and Address) when you display or edit the 
names table. When you pick a station address for a display 
filter, the list of alternatives now shows both Type and 
Address for each name. (See page 161.) 
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® Resolve Names: Lets the Sniffer supply symbolic 
equivalents for addresses in its working names table by 
looking them up in an auxiliary directory file. (See page 
165.) 


S Address-Level Filter: Lets you set a display filter to pass 
only those frames that include an address at one of the 
protocol levels you indicate. When you elect Summary 
display, the name shown is the one for the highest of the 
levels you checked. (See page 167.) 


® Bytes Option: Lets you select Bytes-per-frame and 
Cumulative-bytes-per-frame as displays in the Time field of 
the summary window. (See page 169.) 


e LCD Option: Lets you adjust the Sniffer’s display screens 
for better visibility on an external overhead projector using 
LCD display. (See page 171.) 


® Snap Option between Menu Panels: Lets you replace the 
rolling transition from panel to panel by a quantum leap 
that dispenses with the slide between. (See page 172.) 


@ Save a Range of Frames: Lets you save only the frames 
within a particular range of positions in the Capture Buffer 
when you execute Save. (See page 172.) 


® Click Control: Lets you turn off the audible clicks which 
accompany arriving frames during capture (or playback of a 
capture). (See page 173.) 


© Customer-written Protocol Interpreters: You may write 
your own protocol interpreters and integrate them with 
those supplied with the Sniffer. This Addendum includes a 
complete new version of Appendix C of the Operation and 
Reference Manual. (See page 179.) 
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Traffic Generator 


How to Generate Traffic 


The Traffic Generator permits you to load the network with 
background traffic messages sent from your Sniffer. You can 
specify the addressee, the total length of the frame and the 
interval between frames in milliseconds. You can also specify the 
content of the first sixteen bytes, to control how other stations will 
treat the frames the Sniffer generates. 


Figure Add-1 shows the panel in the main menu from which you 
select the Traffic Generator. Pressing enter at any of the four 
options listed on the right permits you to fill in the value you want, 
or select from the table of destination addresses. 





Figure Add- 1: Pane thowias options for the Traffic Generator. 


The options are as follows: 


Address: Pick one from the list of recognized addresses the Sniffer 
maintains, including both the addresses of specific stations and 
“role” addresses such as “All Stations,” “Lan Manager,” and so 
on. If the address you want isn’t yet on the list, you can amend 
the Sniffer’s list of addresses by selecting New Station. 


Size: The total length of the frame in bytes, from 18 (the 
minimum) to 4048 bytes. 


Interval: The number of milliseconds between the end of one 
frame and the start of the next, from 0 to 1000. 


Data: Thirty-two hexadecimal characters specifying the frame’s 


first sixteen bytes. The first byte identifies the destination SAP, 
the second the source SAP, and the remaining two are control 
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bytes indicating the type of transmission. The figure shows the 
default value 0300, indicating unnumbered information follows. 


After you complete selection of your options and return the 
highlight to Traffic Generator, press Enter to start the Sniffer 
loading the network in the way you’ve specified. When it starts, it 
devotes full attention to the task and so can’t do anything else. 
You'll see a screen showing that traffic generation is taking place 
(see Figure Add-2). The Sniffer continues sending frames until you 
press Esc to stop it and return to the main menu. 





‘Figure Add-2: Screen visible when the Sniffer i Us generating traffic. 


Format of the 
Transmitted Frames 


The format of a frame sent by the Traffic Generator is illustrated 
in Figure Add-3. It shows a frame captured by another Sniffer on 
the network a few microseconds after the originating Sniffer sent 
the frame shown in Figure Add-2). 


The first two bytes are the AC and FC bytes of standard DLC 
header, visible in the hex window as 18 40. 


There follow six bytes of destination address (in this case, cO 00 
FF FF FF FF, which means “Broadcast”) and six bytes of source 
address (in this case, 48 00 OA 00 00 02, which was the sending 
Sniffer’s address). 


Then come the sixteen bytes elected in the panel that generated 
the traffic (Figure Add-1): 00 00 03 00 .... 00. In the detail 
window, the abbreviation “UI” is shown, together with a 
translation indicating that “UI” indicates “Unnumbered 
information.” In the hex window, the first three of those four bytes 
appear highlighted. (The fourth isn’t highlighted because the 
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preceding bytes are sufficient to identify the UT command, and the 
protocol interpreter knows that UI makes no use of the fourth 
byte.) 


0.005. “Broadcast _ +A Sniffer 
O05 Bt “SALELE: 





Figure ald 3: Displas of a sea Fane pee ay ae ‘Sniffer. 


Following the 30-byte header, the rest consist of the dummy 
message. The last four bytes of the frame are a sequence number, 
shown in the figure as 00 00 24 F5. (The sequence number is part 
of the message that the sending Sniffer generated, and not a DLC 
frame number.) The four bytes are a 32 bit unsigned integer 
starting with the most significant byte. 
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Playback 


How to Get 
Playback 


From any of the saved capture files, you can now regenerate the 
display of meters and counters, just as though the packets were 
arriving from the network in real time. You even get the sound 
effects. 


Playback permits you to experiment with the display options that 
are available during capture even when you’re not capturing “live” 
frames. It also makes a convenient way to demonstrate a 
particular sequence to your colleagues, or to introduce the Sniffer 
to people who are haven’t used it. At a tutorial session based on 
playbacks, you can: 


e Observe the dynamics of capture, including changes in 
traffic density and the accumulation of traffic counts. 


6 Experiment with capture filters to weed out 
extraneous frames. 


e Experiment with triggering (that is, freezing the 
capture buffer when a particular trigger pattern is 
received). 

a Experiment with recording only part of each captured 


frame (see Partial Frame Capture, below). 


To run a playback, you don’t have to be connected to the network, 
so you can use it for experiment, training or demonstration even 
when the network is down, or you’re not connected to it. 


In the main menu, move the highlight to Capture, and then to the 
detail panel to the right of Capture. Move the highlight downward 
to the line marked FROM. Beside the word “FROM” you'll see the 
name of the source from which you’re going to capture data. If you 
haven’t yet reset this option, it says Token Ring by default (see 
Figure Add-4) 
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_ New : 





Pe Add-4: Capture menu, showing fi eld labeled FROM indicating s« source ce from which — 
frames will be captured. 


There press Enter to bring up a list of alternative sources from 
which to capture frames. You’ll see a menu that includes all the 
capture files in the current directory (Figure Add-5). (The menu 
also lists the names of any subdirectories within that directory; to 
see what’s in one of the subdirectories, move the highlight to it, 
and press Enter.) 





Figure Add-5: Window showing list of trace files on hick. you may elect to apie ere 
playback. 
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Partial Frame 
Capture 


Move the highlight to the name of the file you want to play back, 
and press Enter. That records your choice and takes you back to 
the panel of Capture options. (You’ll now see your selection named 
in the “FROM” field; see Figure Add-6.) 


From ADEMO.TRC 





To start the playback, press F10 (New Capture), or move the 
highlight leftward to Capture and there press Enter. 


Capture collects captured frames in the Capture Buffer, in the 
same way that they are collected when you’re doing a live capture 
from the network. You can set up capture filters before you start, 
to operate during the capture; after you’ve captured them, you can 
set display filters to select frames from the set in the Capture 
Buffer. You can if you wish save the contents of the Capture 
Buffer to a file, just as you could if the frames had been captured 
live. 


When you want to return to capturing live data from a network, 
use the same procedure but, choose <Token Ring Network> 
instead of one of the files. 


When the frames you’re capturing are long, they may fill up your 
Capture Buffer before you’ve collected a good enough sample. 
That’s most likely to happen when the frames involve substantial 
data transfers on the network. Usually you’re interested only in 
the headers, and not in the data that’s being transferred. In this 
situation, you want partial frame capture. You specify the 
maximum number of bytes you'll accept from each frame; _ the 
sniffer discards the excess characters before they can reach the 
Capture Buffer. 
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How to Get 
Partial Capture 


In the main menu, move the highlight to Capture and then to the 
panel to its right. Within the Capture panel, move up to the top 
line marked Frame Size (Figure Add-7), and from there move 
rightward to the next panel to select one of the four options: 

€ Not more than the first 128 bytes. 

® Not more than the first 256 bytes. 

& Not more than the first 512 bytes. 


@ Whole frame. 





Fi uwure Add-7: Menu to lemit length or rantared. frame. 


Display of Truncated Frames 


Move the highlight to the length you want, and there press the 
space bar to register your choice. These are radio controls: 
selecting one automatically deselects the one previously selected. 


When you display a frame that has been truncated, the display 
nevertheless reports its full length. However, in the hex display, 
you'll see xx to indicate a byte for which the data has been 
discarded (see Figure Add-8). 
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ee ec emer 
060. 1E C4 3D 3B 1E C2 3D 75 09 E8 CA 00 74 02 F9 C3 ..=3..5U... tee. 
: : : 





Figure Add a - Display of be pk that has been as to - 28 bie during capture. a n 
the hex view, bytes which cannot be displayed are represented by x (and by 2 in the ASCII 
transliteration). 
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Higher-Level 
Addresses 


Capture Filters 
Rely on DLC Addresses 


Expanding 
the Name Table 


Every frame on the network contains both the address of the 
station to which it’s addressed and the address of the station 
which sent it. They are included at the DLC level. However, a 
frame may also contain other addresses. Certain protocols permit 
a frame to include within it a message written according to a 
higher-level protocol, and that protocol may provide an addressing 
scheme of its own. 


To illustrate: one of the situations in which this is likely to arise is 
when frames are being relayed through a gateway. At the DLC 
level, a frame’s source and destination may be the gateway 
stations responsible for the current leg of its journey. Within a 
DLC frame, there may be an XNS message embedded. Its source 
and destination addresses are those of the original sender and the 
ultimate recipient, rather than the stations involved in this 
segment of the journey. 


In some higher-level protocols, a frame may be addressed not just 
to a machine but to a process running on that machine. 


The Sniffer now displays and records address at multiple levels; 
the higher levels affect the way the Sniffer filters the Capture 
Buffer for display and what it shows in the display. However, they 
do not affect which frames the Sniffer captures. That’s mainly 
because frames arrive so fast that the Sniffer has to decide 
whether to accept them before the protocol interpreters have had 
time to locate and decode higher level names. Hence capture filters 
operate only at the DLC level. 


As part of every address, the Sniffer’s name table now includes 
the protocol in which the address can occur. This is called the type 
of the address. 


(Although Version 1.0 of the Sniffer was able to show such higher- 
level addresses in its Detail display, its name table did not provide 
a type field, and recorded addresses only at the DLC level.) 


Figure Add-9 shows a portion of the Edit names display, with the 


Type and Address fields for several levels; symbolic names have 
been provided for some of them. 
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sOseel 
22.82 


Figure Add-9: Station names showing type and address fields. 


Maximum Length 
of Displayed Names 


In Figure Add-9, taken from the Edit Names menu, names for 
which no symbolic equivalent has been assigned are shown first, 
followed by those with symbolic names in alphabetical order. 


The various levels at which names may arise permit a variety of 
possible lengths, which in turn may prompt a wider variety of 
symbolic names for them. To accommodate these names, the 
Sniffer now permits you to adjust the width of the source and 
destination fields in the Summary view. The default width is 12, 
but you can make it as low as 6 or as much as 31 characters wide. 
You may assign symbolic names having up to 31 characters. 


When you elect a wide field for names, the summary of the 
frame’s contents may be pushed rightward so that it is no longer 
visible on the screen until you scroll rightward (where you’ll no 
longer be able to see fields at the left of the display). 


If you elect a narrow display, some of your names may appear 
truncated. When it truncates a name, the Sniffer shows two dots 
at the end of the name to indicate truncation. For example, when 
you’ve set a width of 8 and the Sniffer must display a 10- 
character name, it shows the first 6 characters followed by two 
dots; see Figure Add-10. 
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Figure Add-10: Frame containing names sat ae eee ie ‘Some names are re loner 
than the width elected, and are marked as truncated by two trailing dots. 


Displaying 
Symbolic Names 


In the Detail view, the Sniffer shows both each address as actually 
recorded in the frame, and, for each, the symbolic name you have 
assigned to it (if any). 


In the Summary view, the Sniffer shows only one name: the 
symbolic name if one has been assigned, and otherwise the actual 
station address; see Figure Add-10. When you have elected an 
address level filter, within each frame the Sniffer shows the 
address corresponding to the highest of the acceptable levels 
present in that frame. 


When an address has no symbolic alias, the Sniffer shows the 
address as it appears in the frame. Depending on the type (that is, 
the protocol level), the Sniffer adopts a format in which to display 
the address. DLC addresses are shown in hexadecimal (two 
characters per byte), but addresses in other protocols are shown in 
decimal, each byte represented by a number between 0 and 255. 
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Assigning 
Symbolic Names 


Editing the Names Table 


When you start the Sniffer, to set up its working names table, it 
reads from the file startup.TRD a table of station addresses and 
symbolic names for them. As the Sniffer stores frames in the 
Capture Buffer, it amends the working names table by adding to it 
any DLC addresses not yet recorded there. Since the names it 
adds are ones that weren’t already there, it has no symbolic 
equivalents for the DLC addresses that it adds until you edit the 
table, or search for names in an additional reference file. 


In similar fashion, the Sniffer also adds to the table any higher- 
level addresses it hasn’t seen before. However, for higher-level 
addresses, the timing is different. Instead of adding them at the 
moment the frames arrive in the Capture Buffer, the Sniffer adds 
them as it comes across them while generating a display. Thus, if 
you look at the names table after you have put frames into the 
buffer (whether by capturing them or by loading them from a file) 
but before you have displayed the capture buffer, you'll see any 
new addresses at the DLC level. However, you won’t see new 
addresses from higher level protocols until after you’ve displayed a 
part of the buffer that contains them. 


As it responds to your request for display of the Capture Buffer, 
when a protocol interpreter encounters a higher-level name, it 
looks in the names table for a symbolic equivalent. If it finds one, 
it uses the symbolic name in the display. For a higher level name 
not yet mentioned in the names table, the Sniffer uses the 
untranslated address in its display. At the same time, it amends 
the names table to include the type and address of the new higher- 
level name. 


You can manually supply symbolic names for station addresses, 
following the procedure described on page 101. Now that the 
Sniffer treats each name as a pair composed of type and address, 
you assign a symbolic name to a type-and-address pair. You move 
the highlight to one of the pairs already in the name table and 
there press Enter. The Sniffer brings up a window in which you 
are invited to supply a symbolic name, or to delete that entry from 
the working name table, essentially as shown in Figure 5-23 (page 
102). 


The same machine may be referred to by names at different levels 
of protocol. You may if you wish assign the same symbolic name 
to these different levels. Alternatively, you may prefer to make 
your symbolic names reflect the protocol level at which they occur. 
The only restriction is that each type-and-address combination 
may occur in the name table no more than once. 
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Resolving Names 
from an External 


Directory 


Format 


of the Directory File 
Used by Resolve Names 


station 
station 
station 
station 
station 
station 
station 
station 
station 
station 
station 
station 
station 


To help identify the addresses within a particular trace, you may 
have the Sniffer look up symbolic names from an external 
directory. When you ask it to Resolve names, the Sniffer asks you 
to select a file whose extension is .TRD from the current directory. 


In the file you have indicated, the Sniffer looks up each type-and- 
address pair in the working names table for which you have not 
yet assigned a symbolic equivalent. It copies the symbolic name for 
that address from the directory file to the corresponding entry in 
the working name table. During the rest of the current work 
session, whenever an address at that level is called for, the Sniffer 
shows the symbolic name in place of the address. (Note that the 
working name table is discarded when you exit from the Sniffer. 
However, you may save the current use of names by the command 
Save names. That copies the working name table into the file 
STARTUP.TRD, from which the Sniffer will create its initial names 
table next time you run TRSNIFF. 


With the TCP/IP Protocol Interpreter, Network General distributes 
a sample file called Hosts.trp. It contains a list of commonly-used 
higher-level addresses for the Internet protocol JP. You may also 
build your own .trRD files. The Sniffer expects each such file to 
have the format illustrated in Figure Add-11. (That format is the 
same as the one used in STARTUP.TRD.) You may use a standard 
text editor (not supplied by Network General) to build extra .TRD 
files of your own, or to edit STARTUP. TRD or HOSTS. TRD. 


The format of a .tTRp file is evident in the sample shown in Figure 
Add-11. 


"Broadcast" = COOOFFFFFFFF addrtype "DLC" 
"Error Log" = C00000000008 addrtype "DLC" 
"ips1" = [36.10.0.13] addrtype "IP" 
"ips2" = [36.11.0.14] addrtype "IP" 
"ips3" = [36.11.0.23] addrtype "IP" 
"ips4" = (36.2.0.5] addrtype "IP" 
"ipss" = (36.22.0.20] addrtype "IP" 
"ips6" = [36.26.0.54] addrtype "IP" 
"ips7" = [36.26.0.56] addrtype "IP" 
"Mary" = 10005A0033BF addrtype "DLC" 
"Long, 31-Character Station Name" = 400000000002 addrtype "DLC" 
"This Sniffer" = 48000A000001 addrtype "DLC" 
"Tom" = lLOOOSAQO2FEB addrtype "DLC" 


Figure Add-11: Sample directory of station addresses and symbolic names, to illustrate its 


format. 


For convenience in subsequent display, the Save names command 
sorts the rows of the table alphabetically by symbolic name. 
However, Resolve names does not require its .tRD file to be in 
alphabetical order. 


A symbolic name is enclosed in double quotes. A station address 
may be in either of two forms: 
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& For DLC frames: hexadecimal, consisting of twelve 
consecutive characters representing the 6-byte 
address. 


® For IP frames: decimal, enclosed in brackets, one 
number between 0 and 255 for each byte of the 
address, with adjacent bytes separated by a dot. The 
number of bytes must be appropriate to the type. 


A specific type (that is, protocol) must be assigned for each 
address. The type can be stated in either of two ways: 


® Explicitly for each address, by the phrase addrtype 
"xx" following each address (substituting the 
appropriate type for xx). Directories generated by Save 
names show all names in this form. 


® Implicitly, using the current default type. An address 
for which no explicit type is shown is presumed to 
belong to the default type. The default type is initially 
"pic". A line containing only the phrase 


addrtype "Xx" 


resets the default type, and is in effect for all lines 
below it which don’t include an explicit type until 
another line consisting only of addrtype and the name 
of a type. Figure Add-12 shows the same information 
as Figure Add-12, but makes use of default types. 


station "Broadcast" = COOOFFFFFFFF 
station "Error Log" = C00000000008 
addrtype "IP" 

station "ips1" = (36.10.0.13] 
station "ips2" = (36.11.0.14] 
station "ips3" = (36.11.0.23] 
station "ips4" = (36.2.0.5] 
station "ips5s" = (36.22.0.20] 
station "ips6" = [36.26.0.54] 
station "ips7" = [36.26.0.56] 
addrtype "DLC" 

station "Mary" = 10005A0033BF 
station "Long, 31-Character Station Name" = 400000000002 
station "This Sniffer" = 48000A000001 
station "Tom" = 10005A002FEB 


Figure Add-12: The sample directory of Figure Add-11 rewritten to use default types. 
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Address-Level You may set a display filter based on the protocol level of the 

Display Filters names each frame contains. The Sniffer then displays a frame 
from the Capture Buffer only when the frame contains an address 
at one of the levels you have checked. 


A frame is acceptable if it contains any address at the level you 
indicated. You don’t specify a particular address you are looking 
for at that level. 


To set the address-level filters, from the main menu, highlight 
Filters, then Address Level (Figure Add-13). 





Figure Add-13: Display-filters menu, showing option to filter on address level. 


Addendum 167 


When you move the highlight to address level, you'll see to the 
right a list showing the alternatives you may select. It starts with 
the lowest level, DLC, present in all frames. You may check as 
many as you wish (Figure Add-14). When you leave DLC checked 
(which is the default), every frame passes the address-level filter, 
since every frame has a DLC address. When you remove the 
check from DLC, you see only frames that contain one of the 
checked address types. (If you accept only frames of a type that is 
not represented in the Capture Buffer, you’ll see the message No 
frames selected for display.) 





Setting the address-level filter also affects the name that the 
Sniffer uses in the Summary view of each frame. One name is 
shown as the source and one name as the destination for each field. 
The name that appears is the one corresponding to the highest of 
the levels checked in the address-level filter. If that name has been 
assigned a symbolic equivalent in the working name table, that’s 
what the Sniffer shows. Otherwise, it shows the actual address, in 
the format appropriate for that level. 
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Bytes Option When you're displaying data in the Summary View, you have a 


choice of ways to measure the progress through the session. The 
choices include: 


a Absolute time: What the clock recorded when the 
frame was received. 


© Delta time: Interval since receipt of the preceding 
captured frame. 


€ Relative Time: Interval since the receipt of the first 
frame, or from the reference frame you have marked. 


® Network Utilization: Percentage of network 
utilization due to the frame in question within an 


interval surrounding its transmission. 


To those four, the following new options are added (Figure Add- 
15): 


@ Bytes: The total number of bytes in the frame. 
® Cumulative Bytes: The sum of the lengths of the 


captured frames, starting with the first frame or with 
the reference frame you have marked. 




















igure Add-15: Menu to select options in the Summary View, including choice of Bytes and 
Cumulative Bytes. 


At any instant the display will show on the screen only the one 
option you’ve selected. Of course you can change to a different 
option at any time; the screen display adjusts accordingly. 
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How to Get In the main menu, move the highlight to select Display and then to 

Bytes Display the right to highlight Summary. Within the summary panel, move 
to the list of time-display options. Move the highlight to Bytes or 
Cumulative Bytes, and press the space bar to indicate your 
selection. (If you already have a a display on the screen, press F6 
to see the display options, and then F3 to return to the display.) 





foe ‘Add-1 6: “Summary display pine ane sy ae ee in the ies frames. 


Figure Add-16 shows a screen with cumulative bytes displayed. 
The figure is based on the data that appears in Figure 2-16 of the 
Operation and Reference Manual. The display shows that the 
estimate of 9,000 bytes (page 30 of the manual) was close, but a 
little higher than the exact count recorded with the cumulative 
bytes option. 
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LCD Projector 


How to Get 
LCD Display 


Snap Option 
Between Panels 


How to Avoid 
Scrolling 


The Sniffer does not itself include a device for displaying screens to 
a group or class, but it can be connected to an overhead projector 
such as the Kodak Datashow. Projectors of that type use an LCD 
display, usually with dark letters on a bright background, the 
reverse of the display on a computer monitor. The LCD display is 
unable to show color, or to increase its brightness as a way of 
highlighting. | 


To provide an attractive display on an LCD projector, the Sniffer 
now includes two LCD options at startup. When running in LCD 
mode, the sniffer uses reverse video to indicate highlighting, rather 
than the brightness or color contrast of the monitor screen. 


Connect the LCD projector’s input cable to the Sniffer’s RGBI 
connector (see Figure 3-1 in the Operation and Reference Manual). 


When starting the Sniffer, include the parameter Lcp or LCDR in 
the command you type at the DOS prompt (or in the batch file 
that starts the Sniffer), thus: 


C:\sniffer> trsniff lcd 


Using Lcpr instead of tcp reverses black and white in the LCD 
display, and may be preferable in some cases. Note that cotor and 
the LCD options are mutually exclusive. When you elect tcp or 
LCDR for the external projector, that’s also what you see on the 
Sniffer’s built-in monitor. (If the external projection is satisfactory, 
you may prefer to make the built-in display invisible by reducing 
its brightness.) | 


In the Sniffer’s menus, when you move the cursor from one panel 
to the next, the display glides sideways to make clear how you’ve 
traveled. The impression of motion is obtained by displaying 
several screens in rapid succession, each only slightly different 
from the one before, like frames of a movie. In some circumstances 
the redisplay is undesirable. and a crisp “snap” is preferred. 
When scrolling is inappropriate, you now have a way to suppress 
it. 


You can turn off the gliding motion in the main menu panels (and 
also in the displays accompanying the opening of a window) by 
electing the noscroll option at startup. When starting the Sniffer, 
include the parameter NOSCROLL in the command you type at the 
DOS prompt (or in the batch file that starts the Sniffer), thus: 


C:\sniffer> trsniff noscroll 
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Saving Just Part of When you save the frames in the Capture Buffer to a file, now you 
the Capture Buffer may save the entire file (including every frame in it, whether or 
: not displayed), or you may save only a subset of the frames. When 

you limit the frames saved, you may do so in two ways: 


8 Saving only those frames that are accepted by the 
display filter now in effect. 


® Saving only those frames that fall in a specified range 
of frame numbers. 


To save the Capture Buffer, in the main menu highlight Files, and 
then Save. At the top of the panel to the right, you'll see options 
for the range of frames to be saved, and, within that range, 
whether to apply the display filter to select frames to be saved (see 
Figure Add-17). 


or aee trey tat ena a oe ene bees ot te settee 








Figure Add-1 7: Menu to select range of frames to be saved, with option to use the display 
filter to select frames to be saved. 


By default, the menu at first shows the range as First to Last. As 
alternatives, there are rows for From frame x and To frame x. The 
Sniffer supplies proposed values for From and To. You may then 
accept the proposed first and last frames; to do that, highlight 
First or Last and press the space bar. Or you can specify the first 
and last frames directly; to do that, highlight each of the Sniffer’s 
proposed values and press Enter to bring up a window in which 
you can write the frame-number you want. 


The two values the Sniffer at first suggests are the numbers of the 
current frame and the marked frame. If you haven’t yet moved the 
cursor through the display to make a particular frame current, or 
pressed F2 to mark a particular frame, the Sniffer assumes each 
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Printing a Range of 
Frames from the Capture 
Buffer 


Sound Effects 
During Capture 


is frame 1. In that case, the Sniffer at first shows the options 
From frame 1 and To frame 1. 


In the example shown in Figure Add-17, the range between 
current and marked frames runs from 14 to 220. (For this 
purpose, it doesn’t matter which is current and which is marked; 
the Sniffer takes whichever is nearer the front to start its 
proposed range of frames.) 


Just as you can elect to save only those frames that fall within a 
particular range of positions in the Capture Buffer, you can in 
similar fashion elect to print only those frames. This feature was 
present in Version 1.0 of the Sniffer, and the menu is shown in 
Figure 5-24, page 103 of the Operation and Reference Manual. The 
manual didn’t explain where the Sniffer gets its proposals for 
From and To. The mechanism is the same as just described for 
saving a range of frames. 


Speaker clicks during capture are optional and controlled by a flag 
at the bottom of the capture-options menu. 


Different sound effects are produced during capture for each of the 
following events: 


° Trigger found. 
® Buffer is 100% full. 
© Capture has stopped. 


These aren’t affected by the clicks control (they aren’t repeated 
events so whether to permit them to sound is less of an issue). 
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Other Revisions to the Sniffer’s 
Operations and Displays 


Minor changes and 


Enhancements 


The changes since Version 1.0 are listed here. 


Many small cosmetic and readability changes have been 
made to the menus and pop-up windows. 


The order of the send and receive sequence numbers (NS, 
NR) in the LLC and XNS have been reversed for better 


visual alignment of fields in the summary window. 


More of the non-alphabetic special characters may be used 
as part of station names. 


The <Alt> <space> combination reverses all the options 


_ within a menu group, not just those at and below the cursor. 


Various summary lines contain additional information about 
the length of fields they describe. 


The names written to the STARTUP.TRD file when the “save 
names” option is chosen are alphabetically sorted. 


The Sniffer deinserts from the ring when the Sniffer 
program exits. 


Various fatal ring errors are detected and reported better. 


The SNA (LU 6.2) Protocol Interpreter decodes a much 
larger variety of fields and frame types. It also conforms to 
convention by generating only one line in the summary 
window. 


The MAC Protocol Interpreter fully decodes all documented 
subvectors. 


The MAC and SNA Protocol Interpreters examine the ASCII 
vs. EBCDIC flag for the hex display window so that you can 
force the translation of strings in the detail and summary 
windows. 


The LLC (802.2) Protocol Interpreter gives more informative 
messages for invalid LLC frames. 


The SMB and NETBIOS Protocol Interpreters call stub 
procedures for undefined opcodes so they can be easily 
extended for new customer-written opcodes. 
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The SMB Protocol Interpreter shows in the summary line 
the command byte for undefined or customer-extended 
commands. 


The SMB Protocol Interpreter includes in the summary line 
the length and offset of a byte range being Locked or 
Unlocked. 


The Novell Protocol Interpreter uses NCP (“Novell Core 
Protocol”) as its tag instead of NTW (“NetWare”). 


The capture-time display shows the percent buffer 
utilization. 


Many of the screen displays have been made considerably 
faster, particularly in the summary window when display 
filters are active. File and station-name windows with many 
entries also pop up more quickly. 


The cursor line in the detail window is highlighted when the 
window is not selected. 


Various disk and device I/O errors are better handled and 
reported. 


Loading and saving disk files has been made faster. 


Timestamping and reporting frames which cross the 
midnight boundary between days is improved. 


In Dual-view mode, the right detail window auto-scrolls to 
the same protocol level as the left. window if no scroll point 
has been set by moving the cursor in the right summary 
window. 


The Load/Save menu items are no longer action nodes, and 
the Data/Setup menu items are no longer radio buttons, just 
action nodes. This simplifies that area of the menus and 
helps avoids mistakes such as saving “setups” when you 
intended to save “data,” and vice versa. 


The station-name table has been expanded from 100 to 500 
entries, the number of detail lines per frame from 150 to 
200, the number of summary lines per frame from 10 to 12, 
and the summary line width from 100 to 120. 


The PIF formatting routines used by many of the Protocol 
Interpreters are more careful about checking for bad data 
within the frames. 


In Protocol Interpreter displays, an ASCII character with 


the high-order bit on is treated as unprintable rather than as 
the equivalent character with the bit off. 
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e A sample Protocol Interpreter for a simple fictitious protocol 
is supplied as an example for writing custom Interpreters. 


® Pressing the Esc key will immediately terminate loading of a 
trace file. 


e After editing an entry in the symbolic name list, the Sniffer 
displays the newly sorted list, instead of presenting the 
Manage Names menu. 


® The Capture Protocol Filter now accepts frames where either 
the DSAP or SSAP matches the chosen SAP(s), rather than 
just the DSAP. 


@ The MAKEFLOP utility mentioned on page 49 of the manual is 
no longer provided. To make backup copies, see the 
description of the BACKUP command in the COMPAQ DOS 
manual. 
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Miscellaneous Bugs 
and Glitches 
Removed 


It was sometimes possible to scroll up past the first frame if 
relative time mode was selected and display filters were 
active. 


The redundant true-size field in frame data records saved to 
disk, which anticipated the partial-frame capture, was 
sometimes incorrect. (This does not affect the Sniffer, only 
other programs written to read those files.) 


Jumping to a Marked or Trigger frame made invisible by 
display filters sometimes generated an internal error 
message. 


Log scales had 0 as the lower limit; there is no such 
logarithm. 


Some informative status messages from the Network 
adapter were being reported as errors. They are now 
suppressed. 


At initialization the Sniffer sometimes mistakenly warned 
about the computer being slower than it should be. 


With the “Highest level only” option turned off, the Page, 
Home, and End keys in the summary window might not 
move the display far enough. 


The number displayed for “frames accepted” during capture 
sometimes became 99990 because of an arithmetic overflow 
if capture filters were on and no frames were accepted. 


The address field in menus and the capture-time screen 
showed blanks instead of the hex address for some cases of 
stations without names. 


When invoked from the Display Options popup menu, the 
“find names” and “clear names” menu action items did not 
cause the underlying frame displays to be recomputed until 
after a scrolling operation. 


The LLC 802.2 Protocol Interpreter had the codes for RNR 
and REJ frame types reversed. 


The SMB Protocol Interpreter did not recognize return code 
1,33 as “record locked.” 


The SMB Protocol Interpreter would sometimes misinterpret 
a “check dir” response SMB. 


The SNA (LU6.2) Protocol Interpreter often misinterpreted 
Request Headers as Response Headers. 
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@ The NETBIOS Protocol Interpreter did not display the 
correct session number for “Find name,” “Name added” and 
“Name recognized” frames. 


@ The NETBIOS Protocol Interpreter was displaying D=00 
and S=00 for “Session alive” frames for which those fields 
are formally “reserved.” 


® The NETBIOS Protocol Interpreter displayed an extraneous 
“Session Correlator” in the “No Receive” command. 


@ A second or third Sniffer on a single network segment was 
sometimes unable to insert on the ring because of the 
presence of the first. 


® The bar-scale meter during capture was incorrectly 
calibrated and gave readings lower than the actual value. 


& In the “Manage names” submenu, deleting a station whose 
name duplicates an earlier station would sometimes delete 
the earlier station instead. 


® The presence of the Routing Indicator in the source address 
for frames forwarded over bridges sometimes caused 
incorrect choices for the stations in Two-station mode. 


® If “..” (father directory) was chosen during file load and the 
resulting path had only one name but did not start from the 
root of the volume, an incorrect pathname was used for the 
directory to display. 


2 Function key labels were not being restored after the F'6 
popup window for Display Options was invoked and 
removed. 


e Invoking help using F1 when a pop-up error window was 
displayed could result in another error window if help files 
were unavailable. 


® Under various complex circumstances, scrolling up in the 
summary window sometimes produced a “sum_ww 13” or 
“sum _ww 10” internal error. 


i, 
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Appendix C. Extending 
Sniffer Protocol Interpreters 


Overview 


This section describes the rules and conventions for writing 
programs that extend the protocol interpretation of the Sniffer. 
The reader is expected to be familiar with: 


® The general operation of the Sniffer 


@ The frame formats of the token ring Data Link Control and 
the IEEE 802.2 Logical Link Control protocol. 


@ The C programming language and the MSDOS 
programming environment. 


Network General is constantly expanding its suite of optional 
Protocol Interpreters. Before writing your own, check with us to 
see what is currently available. 


A Protocol Interpreter (“PI”) is a routine (or set of routines) which 
is given a pointer to data somewhere within a frame. The 
interpreter has four tasks: 


@ Generate one or more short text lines for its protocol level to 
be displayed in the summary window. 


8 Generate lines for the detail window. 
® Call the Protocol Interpreters for embedded protocols, if any. 


e Optionally supply new symbolic names discovered within the 
protocol data. 


Protocols are initially demultiplexed by LLC DSAPs; = any 
subsequent demultiplexing is done by Protocol Interpreters which 
are aware of their specialized conventions for embedded protocols. 
Protocol Interpreters for embedded protocols may be shared; that 
is, a PI may be called from several other PI’s. 
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Calling conventions for 
Protocol Interpreters 


A Protocol Interpreter function named new pi that you might write 
would be called from the Sniffer as follows: 


int new_pi (frame_ptr, frame_length) 


char *frame_ptr; 


int frame_length; 


char *dlc_header; 


char *llc_ header; 


int llc_type; 


int pi_frame; 


Pointer to frame data 
The length of the frame data starting at frame_ptr 


The pointer to the frame data starts within the physical frame at 
the beginning of the data for the protocol, and thus skips previous 
protocol fields including source and destination addresses, routing 
indicators, LLC control, and any previously-embedded protocol 
data. 


The Sniffer will permit you to truncate frames in storage (for 
example, recording no more than a certain number of bytes for 
each frame, and discarding the rest). When truncation is elected, 
frame_length will be the length of the stored (truncated) data, and 
the global integer bytes_not_present will indicate how much 
additional frame data was not recorded. 


For first-level (“SAP”) Protocol Interpreters called from the SAP 
demultiplexer, frame_ptr is the address of the first byte of the 
information field immediately following the source and destination 
SAPs and the control field. The SAP Protocol interpreter will be 
called for any frame with an information field, such as I, UI, XID, 
TEST, or FRMR. It will not be called for frames which do not 
contain information, such as RR. 


The return value of the protocol interpreter is the number of bytes 
of frame data that were interpreted. This may be used by the 
calling interpreter to decide whether any subsequent interpreters 
are to be called. If there is no more data left to interpret, simply 
return the initial value of frame_length. 


If the Protocol Interpreter needs access to DLC or LLC header 
fields, or the frame number, the following global static variables 
may be used: 


Pointer to DLC header of the frame, starting with the 
AC field 


Pointer to the LLC header of the frame, starting with 
the DSAP field 


The type of the LLC frame; see the LLC_xxx macros in 
pi.h 


The current frame number 


Protocol interpreters for embedded protocols should be invoked 
using the same calling convention. 
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Registering Protocol 
Interpreters 


Protocol interpreters should be registered before they are used. 
Registration is required for first-level (SAP-demultiplexed) 
protocols. It is optional for others, but if done will add a menu 
item which the operator can use to control the display of frames 
which contain your protocol. 


All registration occurs in the function initpi.c which is called 
when the Sniffer is initialized. Registering a Protocol Interpreter 
generates a pointer to a structure which holds data relevant to the 
interpreter. That pointer must be supplied in subsequent calls 
which generate screen output. The pointer should be saved in a 
static variable known to the interpreter. 


struct pi_data *register_pi (menu_title, pi_type, ndsaps, dsaps, new_pi, prefix) 


char *menu_title; 


int pi_type; 


int ndsaps; 


int *dsaps; 


void *new_pi(); 


char *prefix; 


The Protocol Interpreter 
Data Structure 


A pointer to a string which will appear in the menu as a 
selectable item, which the user can use to control 
whether summary lines for that protocol should be 
displayed. It is also used in constructing the messages 
which appear at bottom of the menu window. The string 
should not exceed 18 characters. 


The type of Protocol Interpreter; see pi.h. The most 
common values are PITYPE_SapP for a first-level 
interpreter and PITYPE_EMBEDDED for a nested protocol 
interpreter. 


The number of DSAPs which will be processed by this 
interpreter. If this is an embedded protocol, specify 0. 


An array of “ndsaps” integers representing the DSAPs 
which will be processed by this interpreter. If this is an 
embedded protocol, this parameter is ignored and should 
be specified as a null address. 


The address of the Protocol Interpreter function. 


A pointer to a string to be used as a prefix for lines in 
the detail window. For visual consistency with other 
Protocol Interpreters the string should be in the form 


"xxx: " 


This structure is allocated, and a pointer to it returned, by the 
register_pi() function. Only the fields described below are 
relevant to Protocol Interpreters, and they are booleans which 
indicate what functions are required. The integer booleans, in 
standard C fashion, are 0 if false and non-zero if true. The 
declaration for this structure is part of the file pi.h. 
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struct pi_data { 


int 
int 
int 
int 


int 


‘3 


do_sum; 
do_int; 
do_count; 
do_names; 


recursive; 


Generating output from 
Protocol Interpreters 


Boolean: generate summary lines? 
Boolean: generate interpretation lines? 
Boolean: only count summary lines? 
Booolean: add symbolic station names? 


Boolean: recursive call to get information for another 
frame? 


If do_sum is true, generate summary lines. If do_count is also 
true, then only a count of summary lines is really needed, so for 
added efficiency you may optionally allocate the line buffers but 
omit actually generating the text. 


If do_int is true, generate detail interpretation lines. 


If do_names is true, the operator has selected the Search for names 
menu option. Examine the frame data for embedded station 
names defined by the protocol. If any are found, call the 
add_station_name() function, described later, to enter the names 
into the name table. 


If recursive is true, this is a call from another Protocol 
Interpreter which needs information about some other frame. If 
you do not have the required information, do nothing except call 
any more deeply embedded protocol interpreters that you know 
about. (See the section Dependencies on other frames for more 
information.) 


To generate a line for the summary window from within a Protocol 
Interpreter, first get the address of a line buffer by calling 
get_sum_line(): 


char *get_sum_line (pid) 


struct pi_data *pid; 


Returns a pointer to the line buffer 
The value returned when the interpreter was registered 


Then move a character string, ending with a null, into the buffer 
provided. The length of the string including the null cannot exceed 
MAX_SUM_LINE. For visual consistency of the displayed output, the 
string should begin with a 3-character identification of the protocol 
layer. 


Generating a line for the detail window is similar, except the 
function to get the address of a line buffer also provides an 
optional offset and length of the field within the frame that 
produced the information. This will be used to highlight the hex 
field of the frame when the corresponding detail line is selected. 
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char 


struct pi_data *pid; 


int 


int 


Adding Symbolic Names 


*get_int_line (pid, offset, length) 


offset; 


length; 


to the Name Table 


Returns a pointer to the line buffer 
The value returned when the interpreter was registered. 


The offset from the DLC header of the field which 
generated the interpretation line. 


The length of the field, or 0 if no highlighting is desired. 


The string should be built in the supplied buffer. Its length 
including the null must not exceed MAX_INT_LINE. 


The detail window will normally be automatically scrolled so that 
the top line is the first line for the protocol which is selected in the 
summary window. If you wish some other line of your protocol’s 
detail lines to scroll to the top, you may so indicate by using a 
negative offset when calling get_int_line for that line. 


Summary or detail display lines should be generated only if the 
appropriate boolean in the pi_data structure is true. Embedded 
Protocol Interpreters should be invoked whether display lines are 
generated or not. 


To add a symbolic name and an address to the station name table 
if do_names is true when the Protocol Interpreter is called, call the 
following function if you discover a useful name: 


add_station_name (flagstype, length, addr, name) 


int 


int 


int 


char 


flagstype; 


length; 


addr []); 


name []; 


The type of the address plus option flags; see pi.h for 
definitions. Example: ADDRTYPE_DLC + ASN_NOREPL for a 
datalink-level address whose name is not to replace an 
existing name. 


The length of the address, from 1 to 16. Example: 6 for 
datalink addresses. 


The address for this name. 


The name to enter in the table; 1 to 31 characters 
ending with a NUL. 
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Since names discovered in the protocol data may be transitory, it 
is probably best to use ASN_NOREPL so that if a name was already 
supplied for the address in the startup.trd file it will not be 
replaced. 


Using existing Protocol Existing Protocol Interpreters may be called from newly-added 
Interpreters Protocol Interpreters that have those protocols embedded. The 
calling sequence for each interpreter is as described above. 


The names and dynamic nesting structure of the existing Protocol 


Interpreters are shown below, but note that some of the 
Interpreters are optional and may not be present in your Sniffer. 
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interp_ dic 
interp_ ri 
interp_ mac 
interp_llc 
SAPS 04,05,08,0C: interp_sna 
SAP 80: interp_xns 
interp_smb 
interp_smb_other 
SAP 86: interp_narc 
interp nestar 
interp_xns 
interp_smb 
interp_smb_ other 
SAP AA: interp_snap 
interp_ip 
interp_icmp 
interp_udp 
interp_rpc 
interp_ nfs 
interp_mount 
interp_pmap 
interp_yp 
interp_tcp 
interp_ftp 
interp_telnet 
interp_smtp 
interp_arp 
interp_xns 
interp_smb 
interp_smb_other 
SAP EQ: interp_novell 
interp_xns 
interp_smb 
interp_smb_other 
SAP FO: interp_netbios 
interp_smb 
interp_smb_ other 
interp_sna 
interp_netbios_ other 
SAP FA: interp_ungbass 
interp_xns 
interp_ smb 
interp_smb_ other 
SAP FE: interp_isonw 
interp_isotp 
interp_smb 
interp_smb_other 
interp_othersaps 


This is the structure as of this writing. New Protocol Interpreters 
are being constantly being added; contact the factory for the latest 
list. 
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Advanced topic: 
Dependencies on other 


frames 


Some of the existing Protocol Interpreters call null stuhs to process 
command codes or types that they do not recognize. By replacing 
or modifying those stubs (whose C-language source is supplied), 
you can extend those interpreters without rewriting them. 


Currently both the NETBIOS and the SMB interpreters do this; 
they call interp_netbios_other() and interp_smb_other(), 
respectively, to process unknown message types. The calling 
convention is the same as for registered PIs, and in fact you may, 
if you wish, register your extension of those stubs so that they can 
be independently selected as a display filter. 


In cases where the interpretation of a frame must depend on 
information in prior frames, there are three mechanisms available. 
In increasing order of complexity they are: 


@ The PI can cache, in private static variables, any 
information that will be useful for subsequent frame 
interpretation. Beware, however, that the PI may be called 
to interpret frames in any order. The cache, therefore, will 
only sometimes be valid. 


In order to recognize that cached data is invalid when new 
frames have been loaded or captured, the PI can examine 
the global integer variable data_version which will be 
incremented each time new data is present. 


This is the easiest and most efficient of these frame 
dependency mechanisms, and is sufficient in many cases. 


& The PI can get access to the data in other frames by calling 
the following routine: 


int pi_get_frame (frame_num, p_dlc, p_llc, p_data) 


int frame_num; 


char **p dlc; 


char **] dlc; 


char **p data; 


The desired frame number. The first frame is frame 
number 0. 


The address of a pointer which will be set to the start of 
the DLC header. 


The address of a pointer which will be set to the start of 
the LLC header. 


The address of a pointer which will be set to the start of 
the LLC data. 
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The return value will be the size of the frame if it is 
available. The length will be zero if the frame does not exist, 
or is not an LLC frame, or the DSAP is not one of the SAPs 
handled by the current PI. 


Note that this technique requires the PI to know the offset of 
the its relevant data from the start of the LLC data; in the 
case of embedded PI’s this requires knowledge of earlier PIs’ 
data structures. 


e The PI can request that the protocol interpreters be invoked 
for previous frames by calling the following routine: 


int pi_invoke_pis (frame_num) 


int frame_num; 


Debugging Messages 


The desired frame number. The first frame is frame 
number 0. 


The return value will be non-zero if the frame number was 
valid and the protocol interpreters were successfully called. 


In general this causes protocol interpreters to be recursively 
invoked. They are informed that this is a recursive 
invocation by the recursive flag in their data structure. If 
they have information which is needed by the originating 
interpreter, information may be exchanged by using static 
shared variables; for example, the recursively invoked 
interpreter might check if it is the request frame for the 
currently active response, and indicate what the original 
request was, if so. 


This is the most inefficient of the three mechanisms, but is 
the most general and is entirely independent of earlier 
protocol headers. This is especially important when writing 
embedded PIs which may be invoked from more than one 
protocol stack, or when earlier headers are variable in size. 


To write a debugging message from within a protocol interpreter, 
use the function debug_msg ("Message of up to 100 
characters"). The last 100 such messages are saved in a 
scrollable window which can be made visible using the Shift-F1 key 
and closed using the Esc key. 


Appendix C: Extending Protocol Interpreters 187 


Advanced Topic: 
Using the PIF formatting 
routines | 


Protocol interpreters may be written with the use of no additional 
functions other than those already described and those available in 
the standard C library. For fixed-format data, the simplest 
approach is often to write structure declarations and simply 
format summary and detail lines using the standard sprintf£( ) 
library function. | 


When the data contains many variable-length or optional fields, 
however, using C-language structures becomes quite awkward. To 
address this problem, a series of stream-oriented formatting 
utilities called PIF (“Protocol Interpreter Formatting”) routines are 
available. The use of PIF routines is entirely optional; you may 
write interpreters without them if you choose. 


A Protocol Interpreter that wishes to use the PIF routines makes 
one call to the initialization function pif_init() each time it is 
called for a new frame. The PIF routines then maintain an offset 
into the frame data, called the “PIF offset,” which is used to 
extract data in various forms. There are three general classes of 
routines: 


® Routines that return a data item to the caller begin with 
pif_get_. The PIF offset is not updated. These routines 
may be used to extract data for either the summary line or 
the detail window. 


® Routines that display a data item on a line in the detail 
window begin with pif_show_. The PIF offset is incremented 
by the length of the data item and thus points to the next 
item. 


e Other miscellaneous PIF functions. 


Table C-1 is a summary of the PIF routines that are available, 
and table C-2 is a detailed description of the calling sequences. 
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Table C-1: Summary of: PIF routines. 


pif init 
pif_save 


pif_restore 


pif_get_byte 
pif_get_word 
pif_get_word_hl 
pif_get_long 
pif_get_long_hl 
pif_get_ascii 
pif_get_ebcdic 
pif_get_lstring 
pif_get_addr 


pif_show_byte 
pif_show_word 
pif_show_word_hl 
pif_show_long 
pif_show_long_hl 
pif_show_2byte 
pif_show_4byte 
pif_show_6byte 


pif_show_ascii 
pif_show_ebcdic 
pif_show_lstring 


pif_show_flag 
pif_show_flagbit 
pif_show_flagmask 


pif_show_space 
pif_header 
pif_trailer 
pif_autoscroll 
pif_line 
pif_set 
pif_skip 


Initialize PIF global variables. 
Save PIF info before calling an embedded PI. 
Restore PIF info after calling an embedded PI. 


Get value of a single byte. 

Get value of 2-byte word in low-high order. 
Get value of 2-byte word in high-low order. 
Get value of 4-byte longword in low-high order. 
Get value of 4-byte longword in high-low order. 
Get ASCII characters into a C string. 

Get EBCDIC characters into a C string. 

Get a length/string into a C string. 

Get the address of the current field. 


Display a single byte. 

Display 2-byte word in low-high order. 
Display 2-byte word in high-low order. 
Display 4-byte longword in low-high order. 
Display 4-byte longword in high-low order. 
Display 2 one-byte fields. 

Display 4 one-byte fields. 

Display 6 one-byte fields. 


Display a string of ASCII characters. 
Display a string of EBCDIC characters. 
Display a length/string of ASCII characters 


Initialize to display bits of a flag byte. 
Display flag bit values. 
Display flag bit value if it matches the mask. 


Display a blank line 

Display a detail window header message. 

Display a detail window trailer message. 

Set detail window autoscroll point to be the next header. 
Return a detail window line buffer and advance the pointer. 
Set current buffer pointer. 

Move current buffer pointer backwards or forwards. 
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Table C-2: Detailed descriptions of the PIF routines. 


void pif_init (pi, p, len) /* Initialize PIF globals */ 

struct pi_data *pi; /* Protocol Interpreter’s control block ptr */ 
char *p; 7/* Start of frame data to interpret */ 

int len; /* Length of frame data */ 


Initialize the PIF variables. pP1F_IN1IT must be called by the PI routine before 
any other PIF_xxx routines can be used. 


void pif_save (pd) /* save pif variables */ 
struct pif_info *pd; /* Ptr to area used to save pif state */ 


Save the PIF variables before calling an embedded PI. The caller supplies a 
"pif_info" area (defined in pi.h) into which the current state information is 
saved. The pif_restore routine can be used to restore the state information. 
This should be used before calling an embedded Protocol Interpreter that uses 
the PIF routines if you wish to use the PIF routines after it returns. 


void pif_restore (pd) /* restore pif variables */ 
struct pif_info *pd; /* Ptr to area used to restore pif state */ 


Restore the PIF variables. The caller supplied a "pif_info" area which was 
previously supplied to pif_save. 


char pif_get_byte (delta) 
int pif_get_word (delta) 
int pif_get_word hl (delta) 
long pif_get_long (delta) 
long pif_get_long_hl (delta) 


int delta; 


Fetch a byte, word (2 bytes) or longword (4 bytes) from the frame data at the 
current PIF offset plus the (signed) value of delta. The PIF offset is not 
changed. The "_hi" versions are for multibyte fields stored with the most 
significant byte first. These are macros defined in "pi.h". 


char *pif_get_ascii (offset, len, result_str) /* get asciiz string */ 

int offset; /* offset to string from current pif pointer */ 
int len; /* maximum number of source bytes */ 

char result_str[]; /* destination string */ 


Move a printable ASCIIz string at the current offset in the packet to a C string. 
Unprintable characters are replaced with “.”. The destination string will end 
with a “\0O” even if the source doesn’t. The return value is a pointer to the 
END (null) of the destination string. The PIF offset is not changed. 
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char 
int 
int 
char 


char 
int 
char 


char 


*pif_get_ebcdic (offset, len, result_str) /* Get ebcdic string */ 


offset; /* offset to string from current pif pointer */ 
len; /* maximum number of source bytes */ 
result_str[]; /* destination string */ 


Translate a printable EBCDICz string at the current offset in the packet is to 
ASCII and move it to a C string. Unprintable characters are replaced with ’.’. 
The destination string will end with a ’\0’ even if the source doesn’t. The return 
value is a pointer to the END (null) of the destination string. The PIF offset is 
not changed. If the menus force ASCII display, this calls pif_qet_ascii instead. 


*pif_get_lstring (offset, result_str) /* Get Lstring */ 
offset; /* Signed offset from current position */ 
result_str[]; /* Return ASCIIz string here */ 


Move an ASCIIz Istring from the current offset in the packet to a C string. An 
“Istring” starts with a length byte followed by that number of characters. 
Unprintable characters are replaced with ’.’. The destination string will end 
with a ’\0’ even if the source doesn’t. The return value is a pointer to the END 
(null) of the destination string. 


*pif_get_addr () /* return the data address */ 


Return the address of the field which is at the current PIF offset. This is a 
macro defined in "pi.h". 


char pif_show_byte (prstr) 


int pif_show_word (prstr) 


int pif_show_word_hl( prstr) 


long pif_show_long (prstr) 


long pif_show_long_hl (prstr) 

void pif_show_2byte (prstr) 

void pif_show_4byte (prstr) 

void pif_show_6byte (prstr) 

char *prstr; /* A sprintf() control string */ 


Create a new line in the detail window with the text given in "prstr" and the 
indicated data from the frame. The text should contain a formatting code like 
"%d" or "%x" where the value should be printed. For the longword displays the 
formatting code should be %ld or %lx. For pif_show_2byte, pif_show_4byte, 
and pif_show_6byte there should be 2, 4, and 6 formatting codes, respectively. 
The PIF offset is updated. As a convenience, the byte, word, and long routines 
return the value displayed as the function result. 


void pif_show_ascii (len, prstr) /* Show ascii text */ 
int len; /* Number of bytes to display */ 
char *prstr; 7* control string with an embedded %s */ 


Create a new detail line from ascii text starting at the current offset. The caller 
provides a sprintf control string whose embedded %s is replaced with the ascii 
string copied from frame data using pif_get_ascii. The PIF offset is updated. 
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void pif_show_ebcdic (len, prstr) /* show ebcdic text * / 
int len; 7/* number of bytes to display */ 
char *prstr; 7/* control string with embedded %s */ 


Create a new detail line from EBCDIC text starting at the current offset. The 
caller provides a sprintf control string whose embedded %s is replaced with the 
EBCDIC string copied from frame data using pif_get_ebcdic. (If ASCII 
translation is forced by the menus, this calls pif_show_ascii instead.) The PIF 
offset is updated. 


void pif_show_lstring (prstr) /* show lstring * / 
char *prstr; /*control string with an embedded %s */ 


Create a new detail line from an ascii Istring starting at the current offset. An 
“Istring” starts with a length byte followed by that number of characters. The 
caller provides a sprintf control string whose embedded %s is replaced with the 
string copied from frame data using pif_get_lstring. The PIF offset is 


updated. 
void pif_show_flag (prstr, mask) /* show flag byte a/ 
char *prstr; /* title string: " = %d" is automatically added */ 
char mask; /* mask value indicating which bits to display */ 


This routine displays the value of a byte with bit flags, and sets up the correct 
information for subsequent calls to "show_flagbit". The PIF offset is 
incremented by 1. 


boolean pif_show_flagbit (bit, truestr, falsestr) /* show flag bits */ 
char bit; /* Bit mask for 1 or more bits * / 
char truestr[ ]; /* string to show if any masked bits are on */ 
char falsestr[]; /* string to show if all bits are off */ 


This writes an 8-character field in the form "....1... <string>", indented as 
appropriate for the previous pif_show_flag call. If the falsestr is NULLP, the 


truestr is used for both cases. Return TRUE if any of the specified bits were 
on. 


boolean pif_show_flagmask (mask, value, prstr) /* show flags conditionally */ 


char maskbits; /* Only check these bits */ 
char value; /* Check for this value */ 
char *prstr; 7/* Write this string if matched */ 


Write a detail line for a bit field only if the masked bits are a specified value. 
The line is written in the same format as for pif_show_flagbit. Return TRUE 
if the flag bits were the specified value and the line was written. 


void pif_show_space () /* Gdisplay a blank line ae 


Write a blank line to the detail window. 
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void pif_header (len, prstr) /* Write a header line * 


int len; 7/* Length of area to highlight */ 
char *prstr; /* Header string */ 
Output a header line to the detail window in the standard "-- --- header_text 


----- " format, followed by a blank line. Highlight data starting at the current 
offset for the length specified. This routine does not update the PIF offset. 
This routine saves the header string in the global called called header_msg so 
other routines can use it. 


void pif_trailer () /* write a trailer line */ 


Output a trailer line to the detail window which reports on how much of the 
frame data was used by the interpreter, based on the final position of the 
PIF __ offset. This routine uses the header string saved by "pif__header". 


void pif_autoscroll () “/* set autoscroll position */ 


Make the next header line written to the detail window with pif_header() be 
the one which is scrolled to the top when summary highlighting is done. This is 
necessary only if the next header line is not the first for this registered PI. 


char *pif_line (len) /* get detail line pointer */ 
int len; /* Number of bytes to highlight and advance */ 


Return a pointer a detail line area. The caller also passes a length, which will 
cause the specified number of bytes (at the current PIF offset) to be highlighted 
in the hex window. The buffer pointer is advanced by the number of bytes 
specified. Beware of the side effects if you use this as the first argument to 
sprintf(); no other arguments should depend on the buffer pointer because 
compilers differ in the order of argument evaluation! 


void pif_set (address) 7/* set the PIF offset */ 
char *address; 


set the PIF offset to the distance from the start of the frame data (dlc__header) 
to the specified address. This is a macro defined in "pi.h". 


void pif_skip (delta) /* move the PIF offset */ 
int delta; 


Add the signed delta to the current PIF offset. This is a macro defined in "pi.h". 
char *pif_get_addr () 7/* return frame data address af 


Return the address of the data item at the current PIF offset. This is a macro 
defined in "pi.h". 
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Building a new Sniffer The programming environment for compiling and linking new 
Protocol Interpreters is that of Microsoft C Version 4.0. No other 
C compilers are supported. 


The \newpi subdirectory of the disk contains the files used to 
compile and link a new version of the Sniffer with modified or new 
Protocol Interpreters... Note that the compiler itself is not 
supplied; you must install it and the linker on the disk and modify 
the pat so that they are available. The Microsoft C runtime 
libraries are assumed to be located in the subdirectory 
\tools\mc\lib. 


Files in the \newpi subdirectory are: 


pi.h Standard PI symbols 
pifswitch.h Flags for PI choices 
pifdecl.h Function type declarations 
initpi.c Protocol registration code 
intnetbo.c NETBIOS stub code 
intsmbo.c SMB stub code 

smb.h SMB structure declaration 
sample.c Source of the sample PI 


trsniffc.lib Library of Sniffer core modules 
trsniffp.lib Library of Sniffer PI modules 
build.bat Batch file to build the Sniffer 
installm.bat Batch file to install Microsoft C 
on the hard disk. 
sample.trc Frame data for the sample PI 


The batch file build.bat can be used to compile and link a Protocol 
Interpreter that you write from scratch, or a modified version of 
one of the “stub” interpreters for NETBIOS or SMB: 
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rem This batch file ("build.bat") builds a new version of the Sniffer 
rem with user-written Protocol Interpreters. 


rem Supply the name of the new Protocol Interpreter source module as the 
rem argument to the batch file, as in "build myprot" or "build sample". 
rem If you are extending one of the stub interpreters for NETBIOS or 

rem SMB, then you would say "build intnetbo" or "build intsmbo". 

rem If you are compiling more than one, you should modify this batch 

rem file appropriately, or perhaps use the Microsoft MAKE facility. 


rem We assume that Microsoft Version 4.0 compiler and tools 
rem are located in the path \tools\mc, and that the 

rem Microsoft C libraries are in \tools\mc\lib. 

rem (Note: If you get a linker error about /SE being invalid, 
rem you are using the wrong version of the linker!) 

path \trsniff;\tools;\tools\mc;\dos; 


msc 31 /AL /Oat /J; 
if errorlevel 1 goto :end 


msc initpi /AL /Oat /J; 
if errorlevel 1 goto :end 


link initpi+%1,trsniff,trsniff,trsniffp+trsniffc+\tools\mc\lib\ 

/SE:500 /STACK:10000; 
if errorlevel 1 goto :end 
trsniff 


send 


In summary, the steps to take in writing a Protocol Interpreter 
are: 


® If writing a new PI (or you which to register your extensions 
to an existing PI), modify initpi.c. 


® Write your C module or modify the supplied stub routine. 


e Run the “build” batch file. 


Appendix C: Extending Protocol Interpreters 195 


An Example Suppose that you want to write a new protocol interpreter for the 
“sample” protocol having simple fixed-format data which looks 
like this: 


{1 byte] Device number 

[1 byte] Command type 

[2 bytes] Number of segments 

[20 bytes] Name of owner (asciiz) 


Suppose further that this protocol uses DSAP 44. Using the 
existing interpreter registrations as an example, the following lines 
would be added at the appropriate places in initpi.c to register 
the new interpreter: 


/* In the declaration section... */ 


struct pi_data *pi_data_sample; 7/* ptr to our PI data */ 
int interp_sample (char *, int); /* our PI function */ 
int simple_sap = 0x44; /* Gefine our SAP */ 


/* In the body of the initpi() function... */ 


pi_data_sample = 
register_pi ("Sample SAP", PITYPE_SAP, 1, &sample_sap, interp_sample, "SAMPLE: "); 


In a new module, you would then write your Protocol Interpreter 
with a structure something like this: 
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/* Protocol Interpreter for the Sample Protocol 
#include "pi.h" 


extern struct pi_data *pi_data_sample; 
extern char *dlc_header; 


/* our PI data 
/* start of the frame 


struct sample_header { /* the format of our header 


char device; 
char command; 
int nsegments; 
char owner [20]; 


} 


int interp_sample (header, length) 


7/* our interpreter 


struct sample _ header *header; /* pointer to our protocol header 


int length; 
{ 


if (pi_data_sample->do_sum) { 
sprintf ( 
get_sum_line (pi_data_sample), 
"SMP Device = %d, Cmd = %02xX", 
header->device, header->command) ; 


J 


if (pi_data_sample->do_int) { 
sprintf ( 
get_int_line (pi_data_sample, 
(char *)&header->device - dlc_header, 
2), 
"Device = %d, command type = %02x", 
header->device, header->commanda) ; 


sprintf ( 
get_int_line (pi_data_sample, 


/* length of the data 


7/* summary line wanted 


/* get line buffer 


/* end of summary line 
/* detail lines wanted 
/* get a line buffer 


/* highlight offset 
7* highlight length 


7/* get line buffer 


(char *)&header->nsegments - dlc_header, /* highlight offset 


2), 
"Number of segments = %d", 
header ->nsegments) ; 


sprintf ( 
get_int_line (pi_data_sample, 
(char *)header->owner - dlc_header, 


"Owner = %20s", 
header ->owner); 


7* highlight length 


/* get a line buffer 
/* highlight offset 
7* highlight length 


/* end of detail lines 


/* If there were any embedded protocol after our header, 


we could call the interpreters here. */ 


return length; /* Say that we used up all the data 


J 
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The generation of lines for the detail windows can be simplified by 
using the PIF formatting routines. That section of code. including 
the generation of header and trailer lines, might look like this 
instead: 


if (pi_data_sample->do_int) { /7* detail lines wanted */ 


/* 


pif_ 


/* 


Set up PIF globals. */ 


init(pi_data_sample, header, length); 


Output the header line and highlight the whole header. 
Note that pif _header() does not alter the PIF offset. */ 


pif_header (sizeof (struct sample_header), 


/* 


"Sample Protocol Data Area"); 


Display the fields; each routine advances the buffer pointer 
past the data item just displayed. */ 


pif_show_byte ("Device number = %d"); 
pif_show_byte ("Command type = %02X"); 
pif_show_word ("Number of segments = %d"); 
pif_show_ascii (20, "Owner = %s"); 


/*® 


Write out "End of..." message and check for excess/missing data. */ 


pif_trailer (); 


} /* end of detail lines */ 


You would then build and test the new Sniffer with the command 
“build sample.” 
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Programming and 
Debugging Hints 


The LARGE memory model is used throughout. the Sniffer and 
must be used by your Protocol Interpreters. This means 
that pointers are 4 bytes and integers are 2 bytes, so that 
the symbol NuLLP, not 0, should always be used to represent 
a null pointer. 


Extreme care should be taken in writing protocol 
interpreters, especially in the manipulation of pointers used 
as targets. There is no hardware memory protection, and 
with 4-byte pointers there is no segment addressability 
limitation; every byte in the machine is vulnerable from a 
wayward pointer. 


The Microsoft Codeview debugger is unlikely to be a useful 
tool because of the size of the Sniffer executable module, but 
SYMDEB works just fine. 


Avoid the use of printf() for debugging messages since the 
cursor is off the screen most of the time and the messages 
will not be seen. You can instead insert messages into the 
detail window by using get_int_line(). If you must use 
printf£(), specify DEBUG as a command line parameter when 
invoking the Sniffer, and the cursor will be left on the 
screen. 


If you are decoding headers or data which are large, beware 
of interpreting invalid information beyond the end of the 
stored data. If the data were captured in "partial frame" 
mode the entire frame may not be present; the global 
bytes_not_stored will indicate how much data is not 
present. 


Remember that the 80286 processor which is used in the 
Sniffer stores integers in low-high format. Depending on 
your protocol, you may have to reverse integers for printing 
or calculation. The PIF routines ending in _h1 are useful in 
that case. 


The Microsoft Version 4.0 compiler supports argument type 
checking using ANSI standard function prototyping. The 
#include files provided with the Sniffer have declarations for 
all the documented functions, and you are encouraged to add 
declarations of your new functions. 


The /J flag has been used to compile all modules, which 
makes the default for character variables unsigned. 


As discussed in the Microsoft C User’s Guide, there must be 

a config.sys file which specifies at least FILES=15 in the root 

directory of the hard disk. If not, misleading errors like 
Cannot find xxx.h’ will result. 


If you are using the PIF routines, it is only necessary to use 
pif_save() and pif_restore() if you are calling embedded 


Appendix C: Extending Protocol Interpreters 199 


protocol interpreters and you wish to generate more detail 
window lines from the current interpreter after the 
embedded interpreter has returned. 


200 = The Sniffer: Operation and Reference Manual 


Combined Index 


absolute time 97 
access control 122, 123 
access unit 121 

active monitor 24 


present 14 
Sniffer 24 

active window 92 
zoom 94 

adapter 
reset 55 
token ring 1, 122 

address 
filter 3, 56, 80 
higher level 161 
recognized 85, 124 
saved setup 105 
station 15, 153 
symbolic names for 99, 163 
type 161, 165 
unrecognized 71 


address level filter 168 


addressee 
NETBIOS command to seek 18 
tabulation by 70 


addrtype 
names table 165, 166 


alias for machine name 21 

angle brackets, modifier of station name 20 
ANSI standard 121 

Any station (in address filter) 57 


architecture 
token ring 121 
arrow key 93 
traversing menu 51 


ASCII 
hexadecimal view 82, 174, 175 


AUTOEXEC.BAT 1, 46 


BACKUP 
DOS command 49 


backup Sniffer software 45, 49 
bandwidth 30 

network utilization estimate 71, 98 
bar graph 71 
batch file 

example 26, 28 

search for 30 


bits per second 
network utilization 98 


bootable diskette 49 
brightness control 45 


broadcast 
filter category 56 
find message addressee 20 
message 70 
monitor present 15 
station address 99 


buffer full 
sound effect 173 
stopping criterion 67 


build Sniffer 
custom PI 194 
byte range 
locked or unlocked 175 
bytes 
accepted count 68 
captured frame 159 
cumulative 170 
per frame 170 
per second 30, 121 
summary view 170 


cable 
Sniffer 42 
token ring 1, 122 


capture 
buffer full 67 
continuous 67 
elapsed time 68 
filter 3, 55, 56, 161, 177 
partial 159 
pause and resume 73 
pause during 68 
playback 156 
preparations 52 
procedure 55 
saved setup 105 
start 67 
stop 63 
suppress clicks 173 
when to stop 65 
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capture buffer 
capacity 4 
display 6, 75 
format of saved data files 107 
load with file of saved frames 75, 76 
not in saved setup 105 
position of trigger 65 
print display 102 
print portion 173 
save to file 5, 6, 47, 74, 104 
save portion 172 


CAPTURE directory 46 

Capture options function key 74 

CAPTURING (label on capture screen) 66 
CGA 48, 45 

change path 78 

character translation in hexadecimal view 82 
characters, resolution 45 

check marks in menu 53 

clear names 100 

clear screen function key 73 


click 
suppress 173 


close file 
example 27 


color monitor 2, 43, 44 
vs. monochrome 45 


COLOR parameter to TRSNIFF 46, 171 
COM1 103 

COMMAND.COM 46 

COMPAQ 41 


compiler 
protocol interpreter 200 


composite video 44 
connect 

ring insertion 23 

Sniffer to token ring 42 
contention 123 
context in summary view 6 
continuous capture 67 


count 

bytes 4 

data flow 26 

frames 4 

total bytes and frames 68 

traffic by sender 69 

traffic by station pairs 69 
create new directory 78 
current directory 47, 77 
Data display function key 73 


data flow metering 26, 67 
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data format 
token ring 123 
data format, saved data files 107 
data frame 124 
data-relative offset 62, 65 
date file created 35 
DB-9 connector 42 
monitor vs. token ring 44 
DB-9 connector 2 
decimal format 
IP names 165 
decimal vs. hex offset 62 
delay in delivering message 13 
delimiter 
token ring 123 
delta time 97 
demonstration 
playback 156 
density, traffic 4, 28 
destination 124, 153 
detail view 7, 18, 82, 84 
highlight corresponding hex 93 
protocol level 84, 85 
dictionary of station names 15, 17, 99 
DIR> in list of saved files 77, 157 
directory 
conventions 47 
create new 78 
current vs. path 48 
path not in saved setup 105 
path to different 48, 77 
structure 46 
to run Sniffer 47, 77 
disconnect from token ring 55 
disk drive 41 
diskette to run Sniffer 45, 49 
diskettes 44 
display 
capture buffer 6 
detail view 82, 84 
form of 7 
hexadecimal view 82 
option in main menu 75 
preparations 52 
setting form 82 
Summary view 82, 87 
display filter 5 
address level 168 
procedure to set 80 
protocol 81 
saved setup 105 


DLC 
address level filter 161 
protocol level in detail view 85, 165 


DOS 41 
backup command 49 
directory in which stored 46 
environment 46 
exit to 45, 49, 52 


downstream neighbor 23 


dual viewports 8 
scrolling 175 


duplicate address test 24 


EBCDIC 
hexadecimal view 82, 174 


edit names 17, 72, 101, 162 
ending delimiter 123 

Enter key 53 

environment, DOS 46 

error monitor 25, 99 


error report 
soft error 25 


example 13 
batch file on server disk 26 
insertion in ring 23 
search for batch file 30 
slow delivery of message 13 
SMB frames 16 


exit to DOS 45, 52 


file 
captured frames 74 
example of remote use 27 
handle 35 
name conventions 111 
print to 102 
read 36 
repeated open and close 28 
saved frames 5, 104, 157 
saved setup 105 
server 26 
size and date of creation 35 


filter 
address 56 
address level 167 
capture 3, 55, 56, 156 
display 5, 81 
display, procedure to set 80 
pattern 80 
pattern match 3, 56 
protocol 3, 56, 80 
saved setup 105 
station address 3, 80 


Find name 
NETBIOS command 19 


floppy disk to run Sniffer 45, 49 


floppy drive 41 
format of saved capture files 107 
forwarded message 21 


frame 122 
capture 55 
context in summary view 6 
copied 85 
count total seen 68 
display 6 
filtered out of display 96 
generate traffic 153 
jump to 95 
jump to mark 95 
jump to number 96 
jump to trigger 95 
numbering 78 
partial capture 159 
printing report of 102 
scroll to next or previous 93 
search for pattern 96 
status 124 
traffic generator 154 
trigger 6 
truncated 160 
validity checks 85 


frame copied 124 
frame-relative offset 62, 65 
free token 23 


full buffer 
stopping criterion 67 


function keys 53 
capture phase 73 


go to frame 95 

graphic display of traffic rate 71 
half-byte character pattern 61 
handle 35 


hard disk 1, 42 
organization of directories 46 


hardware 41 

heartbeat, monitor frames 14, 18 
HELP directory 46, 47 

help, on-line 54 


hexadecimal 
highlight parts 93 
message text visible 21 
station address 71, 165 
view 7, 82 
vs. decimal offset 62 


high-water (in transmission display) 67 
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highest-level-only 
difference between screen and printer views 
108 | 
protocol view 89 
summary view 28 
highlight 
active window 92 
hex corresponding to detail interpretation 
93 
home key 93 
IEEE standard 121 
initialization request 25 


insertion in ring 55, 122, 174 
example 23 
interpretation 
frame 9 
highlight corresponding hex 93 
see also detail view 9 
- interpreter 
protocol 16, 115, 179 
interval 
between frames 97, 153 
between monitor broadcasts 15 
IP 
address format 146 
protocol 162 
ISO standard 121 
jump 
to frame 95 
to menu item by typing first letter 76 
keyboard, Sniffer 42 
kilobytes accepted count 68 


Kodak Datashow 
LCD display 171 


LAN Manager 24 
LAN manager, station address 99 
LCD 

parameter to TRSNIFF 171 
LCD display 171 


length 
names in Summary View 162 


level of protocol 
detail view 84 
print vs. screen 103 
summary view 89 


LLC 17 
frame 125 
protocol level in detail view 85 


load data command 77 

logarithmic scale 71 

logical address, NETBIOS protocol 20 
logical link control see LLC 
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look for names 100 
LPT1 103 


MAC frames 14, 125 
character translation 82 
summary view 14, 174 


main menu 44, 50, 52 
figure 51 


make directory 78 
MAKEFLOP program 49, 177 
manage names 99 
Manchester code 123 
mark 
basis of relative time 98 
jump to 95 
partial saving or printing 173 
set 19 
MAU 121 
media access control 125 
memory, Sniffer 42 


menu 
check marks 53, 174 
jump to item by typing first letter 76 
main 44 
Overview 1 
radio controls 53 


Menus function key 74 


message 
delay in delivering 13 
example of transmission 21 
NETBIOS command 18 
phases in transmission 20 
SMB command 16 


meter 
data flow 26, 67 
traffic density 4, 178 


Microsoft C compiler 200 
modifier, station name 20 


monitor 
active 125 
brightness control 45 
built-in 2 
color 2, 43 
color vs. monochrome 45 
contention 123 
frames 14 
LCD 171 
monochrome 42 
no picture 45 
standby 125 
station address 99 
move to frame 95 


multiple access unit 121 


names 
deduced from network messages 100 
dictionary 17, 164 
directories for 48 
editing 72, 101, 164 
file 71 
higher-level 164 
length in Summary View 162 
not in saved setup 105 
resolved from external dictionary 165 
revision 59 
station addresses 15 
symbolic 16, 99, 162, 163, 183 
truncated 163 
updating entries 48 
working copy vs. file 59 
working table vs. STARTUP.TRD file 99 


NETBIOS 
example 3 
in LLC frame 28 
in trigger pattern 63 
logical address 20 
No receive 37 
No receive command 32 
protocol interpreter error 178 
Receive outstanding 32 
network 
Sniffer’s role 2 
topology 25, 121 
utilization 29, 71, 98 
New Capture function key 67, 74, 158 
new directory 78 
new station 24, 71 
New station (in address filter) 57 
next frame 93 
nibble character pattern 61 
no picture visible 45 
No receive NETBIOS command 32, 37 
NOSCROLL parameter to TRSNIFF 171 
Novell protocol 175 
numbering of frames 78, 96 
offset 
frame-relative vs. data relative 65 
hexadecimal vs. decimal notation 93 
pattern 62 
trigger menu 63 
trigger pattern 64 
open file 27, 28 
options saved in setup file 52 
other SAP 
capture filter 60 
custom interpreter for 113, 179 
display filter 81 
packing list 41 


page up/down keys 93 

pairwise tabulation of traffic 69 
panels of main menu 51 

param server 24 

partial capture 158 


path 
different directory 48, 78 
not in saved setup 105 


pattern 
capture filter 61 
filter 3, 56, 80 
saved setup 105 
search for frame 96 
trigger 64 
working copy vs. file 62 


pause 
capture 68 
function key 73 
options during 73 


percentage utilization 71 


playback 156 
clicks 173 


polling, station-to-station 18 
portable 42 
power switch 42 


pretrigger 
percentage of frames in buffer 66 
previous frame 93 
print 
capture buffer 5, 102 
capture buffer (portion) 172 
example 27 
vs. screen display 103 
priority 122 
protocol 
capture filter 60 
custom interpreter 113, 179 
display filter 80 
filter 3, 56 
interpreter 16 
interpreter registration 115 
level of address 161 
level in detail view 84 
print vs. screen 103 
saved setup 60 
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protocol interpreter 
adding symbolic names 183 
calling conventions 180 
compiler 200 
data structure 181 
formatting 188, 189 
inter-frame dependencies 186 
memory model 200 
output 182 
registering 181 
purge ring 23 
radio controls in menus 53 
rate of data transmission 67, 121 
RCA connector 44 
read byte range 
SMB command 36 
read file 36 
example 27 
real-time display 4, 67 
receive outstanding, NETBIOS command 32 
relative time 15, 29, 97 
resolve names 165 
repeated transmission 37 
request initialization, MAC command 25 
reset adapter 55 
resolution, monitor 438, 45 
RESTORE, DOS command 49 | 
Resume function key 74 
reverse direction (station address filter) 56 
RGBI video 2, 44, 171 
ring 
disconnect 55 
insertion 23, 55, 122, 174 
purge 23, 97 
ring architecture 121 
routing information 124 


SAP 
capture filter 60 
traffic generator 153 
other 60, 81 


save 
capture buffer 74, 104 
capture buffer (portion) 172 
format of files 107 
names 99, 165 
setup 8, 105 
saved frames 
load capture buffer 5, 75 
saved setup 60, 62, 105 
schematic view of Sniffer 9 
scrolling 7 
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active view 94 

dual viewports 175 
suppress 171 

view of frame display 93 


search directory 
SMB command 27, 31 


search for pattern 96 
saved setup 105 


send message 
SMB command 16 


sender 
tabulation by 70 


sequence number 155 
SET TRNAMES 48 


setup 

file 55, 67, 105 

pattern saved with 62 

save 52 

save and restore 8 

saved 60 

values saved 105 
size 

generated frame 153 
size of file reported 35 
slots, Sniffer 42 


SMB 
embedded in NETBIOS 28 
example 3, 16, 27, 28 
protocol interpreter error 177 
read byte range command 36 
search directory command 31 
send message 16 
SNA 
character translation 82 
protocol level in detail view 84, 174 
snap option (no scrolling) 171 
Sniffer 
build new, with custom PI 194 
description 1 
hardware 41 
procedure to start 44 
role on network 2 
schematic view 9 
software 44 
symbolic name 100 
soft error 25 
software, Sniffer 44 
sound effects 173 
source 124, 153 
standby monitor present 14 
starting delimiter 123 
STARTUP.TRD file 71, 99, 99, 164, 165 


station address 
filter 3, 56, 80 
saved setup 105 
symbolic equivalent 15, 16 
traffic generator 153 


station names 
symbolic equivalent 99 


status 
frame 124 
stopping capture 


sound effect 173 
trigger menu 63 


SUA (station upstream address) 25 


summary view 7, 82, 87 
address level 168 
example 14 
protocol level 89 
two station format 88 


switch, on-off 42 
T, trigger frame label 66 
Tab key 92 
test file, batch example 26 
This Sniffer symbolic name 100 
time 
absolute 97 
display of 97 
interval between frames 97 


network utilization 98 
relative 15, 29, 97 


token 122 
lost 23 


token ring 
architecture 121 
connection 55 
connector 42 
disconnect from 55 
insertion 55 
speed 121 
standards 121 


topology 121 
deduced from upstream neighbor 25 


traffic 
by station pairs 26 
density 71, 156, 178 
generator 153 
measurement 27, 67 
sound effect 173 
tabulation by sender 70 
tabulation by sender and addressee 4, 70 
tabulation by senders 4 
units to count 71 


transmission rate 67 
TRC, file extension 76, 111, 157 
trigger 55 


detector to scan arriving frames 4 
during playback 156 

effect 5 

frame 6 

half-byte character pattern 64 
offset to pattern 64 

pattern match 63 

procedure to set 6 

saved setup 105 

sound effect 173 


trigger frame 
jump to 95 
position in capture buffer 65 
TRIGGERED (label on capture screen) 66 
TRS, file extension 111 
TRSNIFF.EXE 46, 77 
TRSNIFF.HLP 111 
truncated frame 160 
truncated names 162 
two viewports 8, 22, 90 
two-station format 8, 17, 27, 88 
selection of stations 88, 178 


type 
address 161, 165 
names 164 


upstream neighbor 23, 24 
utilization of network 29, 71, 98 
validity checks 85 


version number 
saved data files 108 
Sniffer 151 
view 
alternative in display of data 5 
decimal 7 
detail 82, 84 
difference between screen and printer 103 
different frames 90 
hexadecimal 7, 82 
multiple windows 86 
scrolling 93, 94 
summary 7, 82, 87 
zoom in active window 94 


viewports, two 8, 90 


window 
active 92 
display 7 


highlight 93 
multiple views 86 
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Xx 
display of truncated frame 160 


XNS 
protocol level 161 


XX 
code for “don’t check” 65 


zoom view of active window 7, 35, 94 
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